昨天講綠燈到底證明了什麼，以及那五種形狀。
今天是最後一天。我原本想替這三十天整理出一個結論，真的回頭看時，留下來的卻不只一件事：有工程上的答案、有重做這套系統才翻出來的東西，也有幾個直到寫完才看清楚的感觸。
它們不完全是同一個題目，卻一直把我推回同一個問題：工具、模型與場域都換掉之後，究竟還有什麼能被帶走？
所以最後一天我不打算用一句「完成了」替自己結案。我會先把前面留下的承諾與限制對一次帳，順便給你一張走過三十天的互動關聯圖，再回頭看這套系統補上了什麼、重做一次為什麼有價值、AI coding 移動了哪些工作與成本，以及這三十天最後改變了我什麼。
最後一天該做的第一件事，是把三十天裡曾經說過、後面要回答的問題重新列出來，讓你自己核對，而不是聽我說都做到了。
回頭讀這個組別的題目說明，裡面列出的模型部署、Agent 架構設計、上下文管理、評估與監控，有幾項正好對上這三十天做過的事。下面用我實際處理的問題來整理，不完全沿用題目說明的名稱：左欄是文章裡真的出現過的說法，右欄是對上的技術面向。
| 我文章裡的說法 | 對應的技術面向 | 做在哪 |
|---|---|---|
| context 隔離、cutoff 時間 T、重送的前綴 | 上下文管理 | 盲讀靠的是那份清單沒有載進那個 subagent（Day 6）、接續上一輪靠一個 cutoff 時間（Day 9）、量出重送的前綴有多少（Day 22） |
| subagent、派遣、六個 Phase | Agent 架構設計 | 六個 Phase，順序不能對調（Day 10）、想按角色歸因，得在被量測物身上做記號（Day 21） |
| 怎麼知道它有沒有變壞 | 評估 | 先用另一個 LLM 當回歸防線（Day 13），再去撞 50 個 benchmark 案例的外部尺（Day 14 到 Day 15） |
| 我要的不是監控，是 profiling | 效能剖析（profiling） | 42 分 28 秒花在誰身上（Day 21）、側錄裡留下多少 HTTP body（Day 22） |
這些名稱不是要把三十天硬塞進另一套分類，而是我做完後才看清楚的共同形狀。還有一個對不上：模型部署。這三十天部署的是 agent 的執行環境，不是模型本身，把模型搬進地端那條路到最後一天還是評估中。
| 前文留下的問題 | 後來的結果 |
|---|---|
| 寫在文件裡的規則，擋不擋得住一個已經拿到能力的 agent，後面用一次真的越界來回答（Day 9） | 擋不住。agent 自己把白名單擴大了（Day 20） |
| 人類寫的 golden comments，有多少條沒通過驗證（Day 14） | 137 條裡 23 條，16.8%（Day 15） |
| 假綠燈先給名字，後面每次再撞到我會標第幾種，最後收攏成一份（Day 13） | 收攏成五形狀（Day 29）。但「後面每次再撞到我會標它是第幾種」只做到一次 |
| 這條線走完，我還會回頭驗一次這些約束是不是真的立住（Day 24） | 驗了，沒立住：跨使用者的網路根本沒有隔離；洞後來補掉了，Day 29 替每個使用者建立一張自己的 docker network |
回頭核對這些跨日承諾與「明天講」的預告，有的是完成，也有的是承認沒有做完。5.75 美金怎麼取樣、後來怎麼變，則留在本篇後面交代。
如果你想換一個角度走過這三十天，我另外把文章、公開 repo、ADR、測試，以及反覆出現的機制與事故接成一張互動關聯圖。它不是另一份結論，也不是完整的承諾底帳；目前圖上先收錄 20 條跨日承諾。它的用途是導航：點進任何一天，都能沿著關聯看這個判斷從哪裡出現，後來落在哪份實作，又由哪支測試守著。圖的最後還有一頁向量導讀：把三十篇切成四百多段，每段算成一個向量，看哪幾天在講同一件事；點任何一點都會跳回原文那一段。
「知道、寫下來、沒有封」是 Day 20 講 DNS 那條出境通道時寫的，它剛好說明了這一節要區分的狀態。
以下談的是已經寫進公開範例 repo 與文章的治理邊界，不是在揭露另一套未公開系統的內部拓樸。三十天裡有十來個地方我停在這個狀態，各挑一個講：網路層是那條 DNS 出境通道，四種補法我列了，也列了各自卡在哪，然後選擇不補；權限層是 rootless，控制平面拿著 host 的 socket 這件事縮不掉，在它補上之前，我先用「跑在一台獨立主機上」把爆炸半徑收在部署層；流程層是發報告前那次人點頭，到今天還是寫在 skill 裡的一句話，不是機制；制度層是既有債的追蹤，我目前只有紀律，沒有機制。
這四個不是同一種狀態。DNS 那條是評估完選擇不補，在 repo 裡是一條講明白的已知限制；rootless 跟發報告前那次人點頭，照我自己在 Day 24 與 Day 27 的說法，是排在待辦裡的，不是評估完決定不做的；既有債的追蹤也一樣，現在是人工開 issue，之後接 GitLab API 自動開就好，只是還沒排進來。前者是這套東西今天真實的形狀；後三者仍是待完成的工作，不能混在一起。
它們的共同點只有一個：都沒有被藏在只有我看得到的待辦清單裡，而是在文章中留下當時的狀態。回頭看我自己的架構圖，只列防線已經不夠了；接受的限制與待辦，也該一起留下。
Day 13 那句「後面每次再撞到我會標它是第幾種」，三十篇裡只照做過一次。Day 18 那台從沒被走過的代理、Day 20 那句「防火牆已驗證」、Day 25 那片抽屜的空白，撞到的當天我一個號都沒標，是 Day 29 回頭才歸類的。「最後收攏成一份」做到了，「每次」沒有。
Day 1 那句「程式碼我會盡量放在公開的 repo 裡」，那個「盡量」是真的有用到：底帳與癒痕不進 runtime 的 skill，也不在公開 repo 裡。準確的說法是程式碼公開了，我在制度上的那本帳沒有。
先把 Harness 這個詞講清楚，因為整個系列都圍著它轉。
Harness 是控制 agent 工作迴圈的一組規格、品質檢查與流程指引。 工具怎麼呼叫、prompt 怎麼設定、流程怎麼走，都在決定它如何工作，也能讓它更不容易犯錯。Claude Code 本身已帶著一套可直接使用的工作迴圈，所以這三十天做的不是從頭打造另一套，而是沿用它，再補上我自己的規則與邊界。
這次更花力氣處理的是另一個問題：打造一個 Sandbox，先把 agent 做錯、做壞時能碰到的資源與損害範圍收住，再配合留在外面的狀態與對帳，降低接續的成本。
一句話分工：Harness 設計 agent 怎麼工作；在這套系統裡，Sandbox 則是其中那層不賭它永遠照規則走的保險，讓越界與失敗的代價仍然可控。 Sandbox 本身不保證復原；能不能接續，還取決於狀態有沒有留在外面，以及重建與對帳的路徑是否存在。
Day 1 那張孫子兵法的表，第一列「先勝而後求戰」跟最後一列「上兵伐謀」，我當時的白話分別是「先把規則和環境架好，再讓 AI 動手」跟「讓錯誤失去發生的條件」。三十天後回頭看，那兩列講的是同一件事，就是 Harness。
而那張表五列裡，最接近 Sandbox 的只有「齊之以武」那半句「環境要擋得下來」；但它講的仍是擋住，不是出錯之後怎麼把損害收住、怎麼接續。這不是漏寫，是我六月站在台上的時候，還沒意識到「出錯之後」需要被當成一個獨立問題。
Day 17 那三個真實事故就是這條線的理由。Replit 的 agent 在使用者全大寫叮囑之下刪掉正式資料庫、Gemini CLI 的使用者按下 Allow Always 之後被 rm -rf 掃出專案外、GPT-5.6 在 Full Access 下誤刪 Mac 上幾乎所有檔案。這三件事出問題的都不是叮囑不夠用力，而是當時的約束與復原機制沒有把損害收住。
而我對這件事的心智模型，坦白講是管理的。
我是走管理路線的那種人，跟 AI 互動是這樣，跟同仁也是。但我用討論的，因為我很清楚所有知識不可能只在我腦中。所以我聽取意見，也接受意見。
人一定有盲點，而且這件事在生理上是字面成立的：視神經穿出視網膜的那個位置叫視盤，視神經纖維與血管在這裡通過，一顆感光細胞都沒有，所以你的視野上有一個真實的破洞，大約在離固視點顳側十五度的位置，約五點五度寬、七點五度高，不是一個小點。平常你不容易察覺它，一方面是雙眼的視野互相補足；即使只用單眼，視覺系統也會拿周圍的亮度、顏色、紋理去把那個洞填起來，這個動作有正式名字，叫 perceptual filling-in（Abadi、Jeffery、Murphy，IOVS 2011）。
想親眼確認，可以打開 University of Washington 的盲點實驗：閉上右眼，用左眼固定盯著右側十字，再慢慢改變自己和畫面的距離；左側圓點會在某個位置消失。頁面下面還有一組中斷的線，可以直接看到大腦如何把盲點補成連續畫面。這不是視力檢查；沒有成功，通常只是距離或固視位置還沒對上。
所以盲點真正的麻煩不是看不見，是「看不見」這件事本身也看不見。 昨天那五種假綠燈，是同一個形狀的東西。
但知道人有盲點，不代表管理者就該把每一步都抓在手上；真正的問題是，放手之後怎麼察覺偏航。
我的主管跟我說過一個比喻，我覺得比我自己想的都好：帶人就像放風箏。讓他飛，但偏航或是浮力不足的時候，要拉一下。
我對 skill 的期待也類似：把必要的指引留下來，同時保留讓 agent 自己發揮的空間。
這個「人該站在哪裡」的問題，六月那場演講我用另外兩個詞講過。那兩個詞來自 Kief Morris 在 martinfowler.com 的 Humans and Agents in Software Engineering Loops：human in the loop 是去改那份產物，或叫 agent 改；human on the loop 是去改產出它的 harness。我當時在台上把它講成一個流程對比：in 是 AI 動一步、人看一下，一個 cycle 一個 cycle 閉環；on 是先把規範與防線定好，AI 在裡面自己跑，能硬擋的由防線擋下，不能硬擋的留下證據，agent 解不了的再回來找人。我拿來套在自己的規則上，就變成：解不了的那些統計下來，改的是規範，不是為個案開一條新規則。
三十天蓋的東西，防火牆、代理白名單、出生證明、退役審查，都是在替 on the loop 鋪條件：人不用握著每一步；該硬擋的由防線擋下，不能硬擋或尚未機制化的，至少留下可追查、可對帳的紀錄。
這就是系統後來補上的東西。至於為什麼明明已經有一套在用的，我還要重做一次，答案在下一段。
先把這次重做的性質講清楚，不然後面的數字會失去比較基準。
在這三十天之前，我手上的 AI Code Review 系統已經經過幾代迭代；skill、dev container 與網頁控制平台，都在實際使用中一路長成今天的樣子。這三十天有沿用、有微調，也有整段重寫與重新製作。它不是「從零完成一套系統」的故事，也不是把某一個原版原樣複製回來，而是把前幾代累積下來的做法，照著我現在理解的問題再描一次。
所以我仍會說這是臨摹。只是臨摹的對象不是一張固定的原稿，而是幾代系統留下來的輪廓。臨摹也不是貶義；重畫一次的過程裡，我翻出了防火牆少寫的兩個引號、翻出代理立在那裡卻從來沒被走過、翻出尾端有 799 秒在重打一份已經寫完的報告、翻出一個沒關的檔案描述符（fd）會凍住一整場。
這幾個問題不能簡單全算在某一個「原版」或這一輪頭上：有些是前一代沿用下來的假設，有些則是重新製作時才出現。真正重要的是，我把每一筆再描一次，才會停在原本視為理所當然的地方；發現之後，相關版本就一起修。
臨摹的價值不是證明哪一版有錯，而是逼你重新驗證每一筆。
順帶更新幾個數字，也把來歷交代清楚。六月那場分享講的是 55% 以上的同仁在用、年化省下約半個人力、單次審查的等值成本中位數 5.75 美金。這三個是當時的觀察與估算，不是這次重新跑的一組 benchmark。這個比例的分母是資訊部負責開發的同仁；半個人力是以每次審查保守估省下十分鐘、換算成一年得來的；5.75 是 skill 上線後最初那段時間、我自己用它經手的 64 次審查算的，報中位數不報平均，因為裡面有幾次離群值會把平均拉歪。
到我寫這篇為止，使用人數有個位數的上升，其餘大致穩定，按 API 牌告價換算，我近期每次審查的等值成本大概翻了一倍。 這不是同口徑的 benchmark：前後觀察期、模型組合與 skill 長度都不同，只能當成一個需要拆解的現象，不能直接歸因。一部分變動是我自己造成的：主線本來用 Opus，現在有些場合會用 Fable（若看 Claude API 全球標準牌告，是 Opus 的兩倍），subagent 則一直是 Sonnet。skill 也一直在長，步驟與審核閘變多，單次要讀的東西自然變多。
另一部分我本來以為是漲價，查了才發現不是。寫這篇的時候，若只看 Claude API 全球標準的 base input／output 牌價，Opus 4.6 跟 Opus 5 一模一樣，都是每百萬 token 輸入 5 美金、輸出 25 美金，一分錢都沒動；這裡沒有把 cache、batch、區域與第三方平台的差異算進去。真正變的在另一個地方：中間的 Opus 4.7 換了新的 tokenizer，Opus 5 也沿用，同一段文字因此可能被切成更多 token。 Anthropic 官方說可能是原來的 1 到 1.35 倍，實際幅度依內容而異（migration guide）；OpenRouter 對超過一百萬筆由 Opus 4.6 轉向 4.7 的文字請求分桶分析，量到 native-token ratio 增加 32% 到 45%，而 2K token 以上 prompt 的正規化成本增加 12% 到 27%，短 prompt 是例外（分析）。快取會吸收其中一部分，但幅度跟 prompt 長度有關。
所以 tokenizer 是值得檢查的因素，但這份外部分析還不能證明它占了我這次成本變動的多少；Fable、流程變長與 tokenizer 各自的影響，仍需要用我自己的請求紀錄拆開量。
Opus 的基本單價沒變，我每次審查的等值成本卻大約翻了一倍。只看單價，還不足以知道跑完一場要花多少。這跟昨天那五種假綠燈是同一族的：不是它騙你，是你量的那個東西，不是你以為的那個東西。 跟計價有關的數字，保存期限比你想的短。所以這些數字不要抄我的，自己量一次：會變的不只是你的用量，也包括模型、tokenizer、快取、流程與計價規則本身。
這件事也決定了我這三十天把賭注下在哪裡。
我用的儀器全部是自架的：Docker、NGINX、iptables、mitmproxy、OpenTelemetry、Jaeger、那幾支掃描器，還有我自己改寫的 ttyd。它們仍會改版、停止維護，也會受授權、供應鏈與相容性影響；差別在於執行環境、資料與替換時機，大多還在我能掌握的範圍。真正綁在特定廠商身上的是被我觀測的那個對象：它的遙測欄位、它的線路行為、它的計價方式、它的使用條款。儀器需要更換時，我有比較大的選擇空間；被觀測的對象變了，我就得重新量一次，但方法還在。
所以我盡量不把結論下在會被改掉的東西上。綁在快速變動之物上的知識，保存期限往往只能用週跟月算；綁在問題上的，可以放久一點。
把方法留下來之後，問題再往前一步：當 AI 能替我印出原本沒有的積木，人還剩下什麼工作？
我平常跟同仁談 AI coding 時，常用一個比喻：寫程式很像堆積木。
以前沒有 AI 的日子，我們就是自己學新東西、蒐集新的積木，遇到不同需求，把積木拿出來拼、建構出一整套流程。你手上有什麼形狀，決定了你做得出什麼東西。
現在不一樣。AI 比較像 3D 印表機：你不需要先有那個形狀的積木，你把構想講出來，它幫你適配、印出合適的形狀。
Day 26 那件事就是最直接的例子。我把一支 C 寫的終端伺服器改寫成 Rust。以前要做這件事，我勢必得先把 Rust 學到一定程度才可能開始；現在我可以圍繞著目標請它做。加速非常多。
但這裡有一個東西沒有被加速：形狀合不合理，還是建立在開發人員的功力底蘊上。
回到工程的基本問題，我仍得知道每個組件負責什麼、彼此怎麼接，以及怎麼確認它做對了。印表機再快，這些判斷也不能省。
從這個角度看，這三十天我交給你的，本來就不是一套成品。
Day 1 我講過一段話：「我用的是 Claude Code，我的 git 在院內的 GitLab 上，我的環境不會跟你一樣。所以每一天我會盡量把『我的做法』跟『這個做法在解什麼問題』分開寫。工具會換，那個問題不會。」三十天寫完，我可以把那句講得更死一點：我給的是積木跟一張問題清單，不是圖紙。
更精確地說，我想留下的不是一套固定做法，而是做法形成以前的判斷：遇到問題時先問什麼、該拿什麼證據、什麼時候不能相信綠燈，以及新的證據出現時，願不願意推翻原來的答案。做法會跟著環境改變，這套判斷才是換了場域仍能帶走的部分。
這也給了我一個驗收標準。你照著這三十天做一次，應該會做出跟我不完全一樣的東西。 我不期待你複製我的形狀；我想留下的是那些形狀怎麼來的，讓你臨摹的是我在描的問題，不是我的筆跡。
反過來說，這三十天對你的正確用法，也是臨摹。不是讀過，是拿你自己的專案照著描一次。我重描自己的系統時，手停在防火牆少寫的那兩個引號上、停在那個沒關的 fd 上；你描的時候，手會停在別的地方。那些停筆處，就是你們家的規則該出生的地方。
但印得出來，不代表每一次都印得對。
會印壞。印壞了只有兩條路。
一是重印。 量大的時候，射出成形通常還是便宜得多；但我們講的是只重印少量成品的情境。此時 3D 列印真正的優勢不是單價，而是它根本不用開模。
這正是 AI 寫 code 改變的地方：重新產生一個版本的邊際成本低了很多；真正昂貴的，往往是後面的驗證與整合。
二是重新塑形。 把它修到成為我們要的形狀。修完可能剛好，可能帶著技術債，但至少「功能」是對的。
而產物做出來之後，人還要不要讀 code、又該靠哪些證據把關，正好是現在業界在吵的題目。
Uncle Bob（Robert C. Martin）在 2026 年 7 月底講了一段話，引起蠻大的討論。他的原話是：
My current strategy is to not read any of the code written by my agents.
（我目前的策略是，我的 agent 寫的程式碼，我一行都不讀。）
他不是放棄品質。他的做法是把 agent 圍在極端的限制裡：單元測試、Gherkin 測試、QA 程序、品質指標、變異測試、覆蓋率，他說還有一大堆。他的論點是，人寫 code 很慢，要拿到 agent 的生產力，人就得從 code 抽身、站到更高一層去管；省下來的力氣，拿去建這套關卡。
Uncle Bob 自己在原文裡用了 run the gauntlet：agent 產生的 code 得穿過他列出的 constraints 與 tests，他才對結果有高度信心。code 可以不給人看，但得先通過那排關卡。
Grady Booch（UML 的三位主要作者之一）持不同意見。依照這篇對其公開回應的整理，測試覆蓋率能增加對功能的信心，卻不能確保 agent 沒有引入漏洞、死碼或效能問題，因此他仍會審查 agent 產生的 code。
這個爭論會卡住，是因為兩邊拿著不同的儀器，卻都在問同一個問題：我怎麼知道眼前的東西是對的？
科學研究也不是先看見世界真正的配線，再把答案抄下來。人先觀察落體、天體運行或疾病在群體裡的分布，提出一個目前解釋得通的模型，再設計新的量測與實驗去找它解釋不了的地方。重力模型能產生可驗證的預測，不代表它是所有尺度下的最後答案；p-value 能描述資料與指定統計模型有多不相容，卻不等於虛無假設為假的機率，也不會替對立假設蓋下「真實」的印章。
如果把同一個問題換到生物醫學，關聯、預測與因果機轉的界線會更清楚。HLA-B27 與僵直性脊椎炎高度相關，病人陽性比例會隨族群而變，也不是每位病人都有。更重要的是，刊於 2025 年卷期的綜述仍明確寫著：目前沒有一個已被確立的完整機轉，可以單獨解釋 HLA-B27 在脊椎關節炎致病過程裡扮演的角色。而 2026 年的證據正往其中一個假說收斂：T 細胞受體（TCR）定序在病人發炎的關節與眼內找到反覆擴增、共用 TRAV21/TRBV9 受體的 T 細胞 clone；把 TRBV9⁺ T 細胞整群清除的抗體，在隨機雙盲二期試驗 ELEFTA 裡讓高劑量組第 24 週的 ASAS40（症狀改善四成的）達標率來到 51.4%，安慰劑組是 24%（Um 與 Paley，2026；ELEFTA 試驗）。2026 年腸道菌相與代謝體研究又補上另一條機轉線索（Huang 等，Gut Microbes 2026）。解析度上升，模型變細，答案仍然不是一句話。觀察到關聯、建立可用模型、弄清楚因果機轉，是三個不同層次。
軟體沒有因此變成不可知的自然界，原始碼仍然可以讀；但面對 AI 產生的複雜 artifact，我們同樣不是只靠一支儀器建立信任。compiler 看靜態語意，測試看指定行為，property test 看不變條件，coverage 看走過哪些路徑，trace 看執行時間軸，封包紀錄看網路上真的送了什麼，benchmark 看時間與資源，而 source review 看內部結構是否還能理解、維護與繼續改。
它們看到的是同一個 artifact 的不同投影。沒有任何一支等於真相；把來源不同、覆蓋邊界也不同的證據疊起來，才會逐步得到一個足以工作的模型。這不是從此不用理解程式碼，而是承認：我們對成果的信任，本來就是由多種證據共同建立，而且只在那些證據真正覆蓋的邊界內成立。 這樣做不是少下結論，而是只把結論下到證據真正支持的位置。
我在意的是下面這個差別：
許多行為測試，是從外部可觀察的結果驗證功能。 它們能說行為符合預期，卻不必然告訴我內部結構是否仍然健康。
我的立場是要管，但不等於每次都由人下去改。我要把定期的結構審查與重構放進 harness，讓 agent 去梳理內部的線路與管線；人負責判斷這套機制有沒有留下未來仍能理解、規劃與調整的形狀。
這一段寫完幾個小時後，我剛好真的做了一次。我把 claude-pty 擠在 sessions.py 裡的責任分三刀拆回各自模組；當時既有測試更新打點與檔名映射後全過，後端覆蓋率仍維持 84%。
隔了半天，我又把 Jinja 與手寫 JavaScript 前端改成 Vue 3；拆除 legacy 的過程與驗收數字都留在 repo。既有視覺驗收沒有觀察到差異，內部則換成 TypeScript、元件、composable 與單元測試，production code 不再靠 innerHTML 拼畫面。
我這週向內部同仁分享時舉了一個例子：較高層的管理者會知道每個人完成工作時的每個細節嗎？不會，也不該靠逐步盯著每個人的操作來管理。他們真正需要掌握的，是目標有沒有達成、責任怎麼分、出了異常能不能被看見，以及現有機制能不能把問題拉回來。
human on the loop 對我也是同一件事。單元測試怎麼跑、內部實作怎麼調整，都可以留在 agent 自己的工作迴圈裡；我不必逐行接手，而是要確保 harness 能暴露結果與風險。成果不對時，我優先修正產生它的機制，而不是每次自己下去收拾。
當然，同仁能承擔專業責任，AI 不能；所以交給 AI 的這條 loop，反而更需要可以驗證的回報與防線。
而要讓這條 loop 真正能被人接手，光留下測試結果還不夠；做過哪些判斷、又是什麼證據推翻它，也得留在程式碼之外。
所以這次我刻意要求 AI 不只交程式碼，也要留下 ADR 和工作日誌。ADR 記最後採用的決定；工作日誌則連一開始猜錯什麼、哪個探針推翻它、測試為什麼改成那樣，都留下來。最後真正能被下一個人接手的，不只是 Vue 元件，而是這次改寫曾經相信過什麼，又怎麼知道自己錯了。
但我是對的嗎？Only time will tell.（唯有時間可以證明。）
我不打算在這裡假裝有答案。倒是有一件事，是我從兩邊的做法裡看到的共同點：要有治理規範，方向才有機會被說清楚、被檢驗，偏掉時也有機會被拉回來。 Uncle Bob 把 code 送去 run the gauntlet 的做法是治理，我的 skill 加容器加對帳也是治理。我特別在意的是，驗收之外，還要留下日後能理解與調整的結構。
上面回答的是 AI coding 改變了什麼。寫完這三十天，我還看到另一組比較偏向自己的改變。
回頭看這三十天，真正的變化不在於又多會了一項技術，而是我開始把工作拆開、交給不同的 agent 同時進行，也更清楚看到：人的注意力才是瓶頸。
一個實際的下午長這樣。本地開著兩三個 Claude Code，一個在寫文章、一個在改 code 實作、一個在校稿；雲端再開一個平行跑，處理那些可以獨立於環境的工作，例如把工具改寫成 Rust、或是把 benchmark 整套跑完。
這件事有效，但我要老實講代價：工作切換（context switching）對人真的是很累的事情。
不是累在打字，是累在每次切回去都要重新讀懂它做到哪、剛剛的決定是什麼、我上一句話講了什麼。機器可以同時跑很多工作，不會承受人類那種注意力切換的負擔；但最後的理解、協調與整合，成本仍然落在人身上。
所以後來我也用上 handoff 這類 skill，讓一段工作可以被交出去、被延伸、被接續。那不是為了讓 AI 更聰明，是為了讓我自己少記一點東西。
第二件事，是我一直在做但從來沒寫下來的。
至少對我而言，我往往感覺得出一段文字帶著 AI 的口音。
我不是靠偵測工具，而是靠自己熟悉的句型與節奏。早期的線索是「至關重要」這類用詞；最近則常是密集的破折號。它們不是 AI 文字的鐵證，卻足以提醒我重新讀一次：這究竟是不是我真的會說的話？
這件事在這三十天發生了非常多次。我對這個系列的每一篇都做過同一件事，把不像我的句子退回去重寫。
我現在比較願意把它叫作編輯習慣：不必證明一句話是不是 AI 寫的，而是回頭問自己，這是不是我真的會說的話。它不好寫成規則，但可以透過反覆重寫養成。
有意思的是，這個判斷習慣在程式碼上我沒有觀察到。 我看不出「這段 code 是 AI 寫的」，反而覺得它在寫 code 的時候更願意去模仿專案既有的樣貌。
這個不對稱我還沒有解釋，但它至少提醒我 skill 的篇幅該放在哪裡。通用的程式設計知識不必在 skill 裡重講成一本教科書；「我們家怎麼做事」，以及哪些品質邊界不能跟著既有程式碼一起模仿，才是不能省略的部分。
這也回頭修正了我在 Day 16 講的那個預測。我當時說 skill 會愈來愈薄，教學型的條文會一條一條退役，結果第一輪退役審查跑完，十六條裡一條都沒退。現在回頭看，我覺得那個猜想方向沒錯，只是時候還沒到。而且有一個變數我當時沒算進去：我這份 skill 現在不只我在用，也不只在一種模型上跑。 要餵給不同家的模型，那些「我們家怎麼做事」的條文就更不可能靠內化解決。
六月那場演講，我最後給的行動是「今天就為你的專案寫一份 AGENTS.md，零元，不用會寫程式」。
這三十天下來，我想給的是它的前一步：先找出那件經常需要你、也耗掉你很多時間的工作。
我用的判準就三個問題：
三個都是的話，那就是它了。我的答案是 Code Review，所以我選它當題材做了這一整套。
這裡有一件事值得單獨講。這個系列從頭到尾都在量測，量 benchmark、量 token、量封包、量那 799 秒。但選題目這一步我沒有先量，也不認為每個人都需要先量。
完整量化本身需要研究成本，不一定適合拿來當選題的第一步；自己的體感可以先決定哪一題值得驗。分工其實很清楚：體感決定從哪裡開始；量測再回答原來的判斷對不對。
選題定下來後，開頭那個問題還差最後一塊：那些帶得走的判斷，我自己是從哪裡帶來的。
參加鐵人賽對我來說是給自己一個交代。我以前就看過、也買過鐵人賽的文章跟書，確實從裡面學到東西，所以一直覺得一定要參加一次。剛好這一整套是我自己做起來、覺得很有成就感的東西，而且過程中有 AI 的鼎力協助，大幅縮短了落地的時間。
而我最後想留下的，是一件我自己也是最近才看清楚的事。
我大學讀的是醫學檢驗暨生物技術學系，考過國家考試、拿到醫事檢驗師的資格，但沒有執業過。
沒有執業，不代表那幾年沒有留下東西。那幾年的訓練，練的是三件事：要有證據才願意接受一個結果、對品質有自我稽核的要求、以及除錯時的方法論。
這三件事我後來全部帶進了軟體工程，一件都沒有丟掉。Day 15 我不肯採信自己那張漂亮的成績單，跑去請一個沒有 context 的稽核員找出偏袒自己的地方，那是第一件；Day 13 我懷疑自己的綠燈，把答案印在教材裡的測試案例燒掉，那是第二件；Day 29 那五種形狀，整篇都是第三件。
它們是 transferable skills。 換了一個領域，工具全部不一樣，但那套判斷是同一套。
寫到這裡我自己愣了一下，因為那句話還有第二層意思：
這好像也正是 AI Agent 在追求的，skill 的形體。
我們在做的事，說穿了就是把一個人身上那些換了場域還帶得走的判斷，抽出來、寫下來、讓它可以被載入。第三天我叫它「萃取一個我」，那時候我以為那只是一個工程手法。
三十天寫完我才想清楚，那不是手法。那是我自己職涯裡已經發生過一次的事，只是這一次，我把它寫成了檔案。
三十天，謝謝你看到這裡。
iThome鐵人賽
看影片追技術